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Specification  for  Interoperability  Between 
Ballistic  Imaging  Systems: 

Part  1 - Cartridge  Cases 


1.0  INTRODUCTION 

Ballistic  imaging  systems  provide  firearms  examiners  or  other  trained  operators  with  computer-based 
analysis  tools  to  review  and  possibly  link  evidence  to  a crime.  These  systems  use  the  powerful 
searching  capabilities  of  the  computer  to  match  representations  of  images  of  recovered-bullet  or 
cartridge-case  crime-scene  evidence  against  representations  stored  in  a computer  database.  An  analyst 
can  create  digitized  images  of  the  evidence  that  are  used  along  with  General  Characteristic  Descriptors 
(GCD)  to  create  electronic  “signatures”  of  the  evidence.  These  signatures  are  then  compared  to  the 
database  entries  and  a ranking  based  on  probability  of  match  is  returned  and/or  candidate  images  are 
returned  for  examination.  In  all  cases  the  final  match  is  confirmed  by  a trained  firearms  examiner  with 
access  to  the  original  evidence. 

Up  to  200  Federal,  State,  and  local  forensic  laboratories  could  make  use  of  such  imaging  systems  to 
perform  ballistics  imaging  for  law  enforcement  purposes.  As  of  December  14,  1995,  a significant 
number  of  laboratories  already  had  or  were  scheduled  to  receive  one  of  only  two  systems  currently 
available:  Drugfire™,  developed  by  the  Federal  Bureau  of  Investigation  (FBI)  through  a contract  with 
Mnemonic  Systems,  Inc.  (MSI);  or  IBIS™,  produced  by  Forensic  Technology,  Inc.,  (FTI)  and  used  by 
the  Bureau  of  Alcohol,  Tobacco,  and  Firearms  (ATF).  It  is  acknowledged  in  a Memorandum  of 
Understanding1  (hereinafter  referred  to  as  the  MOU)  that  it  is  imperative  that  Drugfire  and  IBIS  are 
interoperable.  “Interoperability,”  as  defined  by  the  MOU,  exists  if  the  systems  are  able  to  (1)  capture 
an  image  according  to  a standard  protocol  and  in  conformity  with  a minimum  quality  standard,  and  (2) 
exchange  images  electronically  in  such  a manner  that  an  image  captured  on  one  system  can  be  analyzed 
and  correlated  on  the  other. 

To  facilitate  the  development  of  interoperable  systems,  a series  of  meetings  was  held  at  the  National 
Institute  of  Standards  and  Technology  (NIST)  on  January  22  and  January  24,  1996,  with 
representatives  from  the  Office  of  Management  and  Budget  (OMB),  the  FBI,  ATF,  NIST,  and  the 
system  vendors  MSI  and  FTI  attending.  As  a result  of  discussions  at  these  meetings,  the  group  agreed 
that  a NIST  Interagency  Report  (NISTIR)  should  be  created  to  define  a minimal  specification  for 
interoperability. 


1 MEMORANDUM  OF  UNDERSTANDING  between  the  Office  of  National  Drug  Control  Policy 
(ONDCP),  Executive  Office  of  the  President,  the  Federal  Bureau  of  Investigation  (FBI),  Department 
of  Justice,  and  the  Bureau  of  Alcohol,  Tobacco,  and  Firearms  (ATF),  Department  of  Treasury,  dated 
January  11,  1996. 
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The  meeting  participants  also  agreed  that  although  the  Drugfire  and  IBIS  systems  successfully 
accomplish  the  same  objective,  they  use  two  fundamentally  different  methods  to  capture  images:  The 
Drugfire  system  acquires  images  created  with  oblique  lighting  (i.e.,  off-axis  illumination);  and  the  IBIS 
system  acquires  images  created  with  annular  lighting  (i.e.,  axially  symmetric  illumination).  These  two 
types  of  images  are  dissimilar  in  appearance  and  content.  Consensus  was  also  reached  on  the  statement 
that  it  has  not  been  proven  possible  at  this  time  to  electronically  translate  the  native  images  generated 
by  either  system  to  an  image  compatible  with  the  other  system,  in  part  because  of  the  differences  in 
lighting  technique  (oblique  vs.  annular).  Rather  simple  arguments  were  expounded  to  show  that 
features  visible  with  one  type  of  illumination  (e.g.,  oblique  lighting)  could  be  invisible  with  the  other 
type  of  illumination  (e.g.,  annular  lighting) — and  vice  versa — when  using  charge-coupled-device 
(CCD)  imaging  systems  with  limited  dynamic  range.  The  possibility  of  future  research  leading  to  a 
method  for  electronic  translation  exists;  however,  the  time  estimated  for  successful  completion  of  such 
research  exceeds  by  at  least  an  order  of  magnitude  the  time  allocated  for  the  development  of  an 
interoperability  solution  under  the  MOU. 

Finally,  to  require  that  either  system  vendor  revise  its  method  used  to  acquire  image  data  to  be 
compatible  with  the  other  system  would  also  require  major  revision  of  the  software  and  proprietary 
algorithms  used  to  generate  the  electronic  signatures  and  search  matches.  This  was  not  deemed  feasible 
by  any  of  the  meeting  participants. 

Based  on  the  above  assumptions  and  conclusions,  it  was  decided  to  produce  a specification  that  would 
require  the  following:  Each  system  shall  have  the  capability  to  acquire  images  that  can  be  transmitted 
to  and  correlated  on  the  dissimilar  system.  This  may  require  hardware  and  software  modifications  to 
either  or  both  systems.  It  was  deemed  the  responsibility  of  the  relevant  government  agencies  and 
system  vendors  (FBI,  ATF,  MSI,  and  FTI)  to  provide  NIST  with  current,  accurate,  and  complete 
information  to  permit  the  successful  specification  of  such  capabilities. 


1.0.1  DEFINITIONS 

The  following  basic  definitions  are  presented  for  the  purposes  of  encouraging  clear  and  unambiguous 
understanding  of  the  concepts  presented  in  this  document: 

Image:  An  image  is  a bit-mapped  grayscale  representation  of  forensic  evidence,  encoded  in  either  a 
lossless  or  lossy  Joint  Photographic  Experts  Group  (JPEG)  format. 

Query:  A query  is  a request  to  match  provided  forensic  image  and  auxiliary  information  against  a 
database  of  forensic  information.  The  query  must  include  all  the  information  required  by  the  target 
system  and  specify  what  information  is  requested  in  return.  The  query  will  be  in  the  format  of  a 
Ballistics  Data  File  (described  below). 
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Ballistics  Data  File  (BDF):  A BDF  is  a collection  of  one  or  more  electronic  files  designed  to  permit  the 
transfer  of  forensic  information  between  ballistic  imaging  systems.  The  BDF  may  contain,  but  is  not 
limited  to,  one  or  more  images  with  auxiliary  data  which  may  include  general  rifling  characteristics, 
laboratory  identification,  specimen  identification,  operator  identification,  date  of  incident,  date  of  image 
generation,  image  characteristics  (size,  magnification,  etc.),  and  query  information.  The  format  of  the 
BDF  is  specified  in  Section  3.0. 


1.1  PURPOSE 

This  document  is  the  first  in  a series  of  planned  documents  that  will  specify  the  hardware  and  software 
requirements  to  permit  interoperability  between  the  Drugfire  and  IBIS  systems  as  specified  by  the 
MOU.  The  purpose  of  this  first  document  is  to  define  a specification  that  will  permit  cartridge-case 
image  capture  and  electronic  exchange  of  cartridge-case  image  information  between  the  Drugfire  and 
IBIS  ballistic  imaging  systems.  Requirements  for  imaging  and  correlation  of  bullets  will  be  addressed  in 
a future  publication. 

Interoperability,  as  defined  by  the  MOU,  is  the  capability  of  acquiring/creating  ballistic  images  and 
auxiliary  data  (a  Ballistics  Data  File)  on  either  system  and  electronically  transmitting  that  data  to  the 
dissimilar  system  in  such  a manner  that  the  image  and  auxiliary  data  can  be  analyzed  and  correlated  on 
the  dissimilar  system.  It  is  recognized  that  from  the  standpoint  of  the  user,  expansion  of  this  minimal 
definition  may  be  desired  to  provide  efficient  operation;  in  particular,  improvements  in  rapid,  automatic, 
and  unattended  image  transfer  and  correlation  would  greatly  benefit  system  users.  Extension  of  the 
minimal  interoperability  definition  is  considered  by  the  MOU  in  Section  IV,  subsection  C,  “Future 
Standards,”  which  requests  NIST,  in  coordination  with  the  American  National  Standards  Institute,  to 
sponsor  the  development  of  future  standards  for  the  capture  and  transfer  of  scanned  firearm  ballistics 
information.  Later  publications  can  be  produced  to  address  these  issues. 

With  regard  to  image  acquisition,  the  concept  of  interoperability  is  not  a yes/no  situation  but  rather  a 
matter  of  degree  of  interoperability.  It  must  be  recognized  that  acquiring  images  on  a non-native 
system  may  produce  subtle  differences  in  image  “quality”  that  could  result  in  changes  in  the  match 
probability.  To  investigate  adequately  the  effect  of  all  expected  differences  against  all  reasonable 
image  databases  would  require  a complex  long-term  research  project  that  is  beyond  the  scope  of  this 
project.  However,  small  variations  in  match  probability  are  already  tolerated,  since  even  within  a 
system  type  there  can  be  small  system  hardware  variations  or  operator  differences.  Thus 
interoperability  must  not  be  defined  as  requiring  “identical”  images  from  the  dissimilar  system  but 
images  that  will  produce  “good”  correlations  or  matches  on  the  dissimilar  system.  At  present  we  do 
not  have  enough  information  to  quantify  “good,”  but  we  expect  that  the  basic  specifications  detailed 
below  will  support  a reasonable  definition  of  interoperability  for  cartridge  cases.  Remaining  quality 
issues  can  be  investigated  during  field  tests  of  the  modified  systems,  and  likely  be  resolved  with  minor 
adjustments. 
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The  proposed  scenario  for  a data  transaction  consists  of  the  following: 

1 . Image  generation  hardware  used  to  capture  one  or  more  cartridge-case  images  compatible  with  the 
host  target  system  is  provided  with  the  remote  laboratory  query  system. 

2.  Sufficient  auxiliary  information  to  specify  the  evidence  fully  and  document  the  query  is  manually 
entered  into  the  system  and  incorporated  into  a Ballistics  Data  File  (BDF).  The  query  may 
reasonably  request  the  return  of  only  that  information  that  the  target  system  may  be  capable  of 
returning.  The  format  and  content  requirements  of  the  BDF  are  specified  in  Section  3.0. 

3.  The  BDF  is  transmitted  electronically  from  the  remote  laboratory  query  system  to  the  host  target 
system  through  standard  voice-grade  telephone  lines  and  commercially  available  modems.  System 
transmission  capabilities  are  specified  in  Section  4.0. 

4.  The  host  target  system  returns  the  requested  information  (if  possible)  consistent  with  the 
specifications  using  the  BDF  format  as  described  in  Section  3.0. 

5.  The  process  (1  through  4)  may  be  repeated,  in  full  or  in  part,  until  the  desired  information  is 
obtained. 


1.2  SCOPE 

For  successful  system  interoperability,  two  requirements  must  be  met:  (1)  each  system  must  have 
sufficient  capability  to  produce  the  required  data,  and  (2)  proper  operating  procedures  must  be 
established  to  produce  data  of  sufficient  quality.  This  specification  will  focus  only  on  the  former  and 
will  establish  a minimum  range  or  boundary  conditions  on  the  hardware  capability  with  an  emphasis  on 
being  as  open  as  possible.  An  example  specification  could  state:  “An  oblique  light  source  adjustable 
from  an  angle  of  55°  to  65°  with  respect  to  the  specimen  is  required  and  the  specimen  cartridge  case  is 
required  to  be  capable  of  being  tilted  from  0°  to  10°  from  normal.”  The  exact  angles  needed  to 
produce  a quality  image  will  depend  on  the  nature  of  the  specimen  and  is  an  operational  consideration. 
Although  operator  experience  is  understood  to  be  crucial  to  both  systems,  it  is  the  responsibility  of  the 
system  vendors  and  sponsors  to  provide  quality  training  and/or  user  manuals  to  specify  the  operating 
procedures  necessary  to  achieve  interoperability. 

This  document  is  designed  to  provide  a complete  specification  of  hardware  requirements  for  the 
capture  of  cartridge  images  (and  ancillary  data)  for  each  system.  In  addition  to  hardware  requirements, 
there  may  be  software  functions  that  must  be  implemented  by  one  or  both  systems  to  generate  or 
accept  the  non-native  cartridge-case  images  and  also  perform  proprietary  processing  before  a 
correlation  can  be  performed.  This  document  does  not  directly  address  how  the  software  functions  will 
be  implemented;  rather,  it  specifies  the  format  and  content  of  the  data  to  be  exchanged.  It  is  the 
responsibility  of  the  system  vendors  to  implement  the  appropriate  software  functions  as  required  by 
their  system.  Cooperation  between  the  vendors  is  expected  to  provide  assistance  in  developing  non- 
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proprietary  operational  procedures  for  identifying  the  required  cartridge-case  characteristics  as 
specified  in  the  BDF  described  in  Section  3.0. 

This  document  does  not  restrain  future  system  upgrades.  However,  as  much  as  practical,  the  system 
vendors  are  encouraged  to  provide  backward  compatibility  to  the  specified  BDF  format  that  will 
permit  data  acquired  on  legacy  hardware  to  be  searched  successfully  on  newly  created  databases.  It  is 
understood  that  the  elements  of  forensic  databases  may  be  of  relatively  temporary  value,  and  the  entire 
database  could  in  time  be  supplanted  by  a significantly  improved  database  structure.  Thus,  future 
improvements  to  the  systems  are  not  restricted  with  any  requirement  that  newly  created  databases  be 
completely  compatible  or  searchable  with  data  generated  according  to  this  specification. 
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2.0  IMAGE  ACQUISITION— FUNCTIONAL  REQUIREMENTS 


A schematic  of  a simplified  optical 
configuration  for  ballistic  imagery  is  shown  in 
Figure  1.  Two  types  of  light  sources  are 
indicated  here:  oblique  lighting  and  axially 
symmetric  (annular  or  ring)  lighting.  The 
cartridge  is  the  object  in  the  object  plane.  The 
objective  lens  (and  any  other  lenses  in  the 
system,  such  as  a relay  lens  between  the 
objective  lens  and  the  camera)  images  the 
object  (the  cartridge  case)  in  the  object  plane 
onto  the  image  plane  on  the  surface  of  the 
detector  in  the  camera.  There  is  a preferred 
optical  axis  that  is  usually  defined  by  the 
objective  lens  and  center  of  the  camera.  The 
requirements  listed  here  refer  to  system 
capabilities  and  are  to  be  distinguished  from 
any  procedural  requirements  or  requirements 
that  may  be  referred  to  as  an  “art”  or  practice; 
that  is,  these  specifications  relate  to  the 
capabilities  of  the  data-collection  system  and 
do  not  attempt  to  define  the  requisite 
competence  of  the  operator.  The  resulting  digitized  image  will  have  an  approximately  square  pixel,  the 
aspect  ratio  (width/height)  of  which  will  be  included  in  the  Ballistics  Data  File  (BDF). 

There  are  several  types  of  images  that  can  be  associated  with  ballistics  data.  We  specify  here 
requirements  for  those  images  using  pristine  samples.  There  are  three  main  properties  of  the  system 
that  spatially  specify  the  optical  configuration  to  permit  proper  imagery:  (1)  The  magnification  of  the 
microscope  objective  used  or,  alternatively,  the  resolution  of  the  optical  system  required  (since 
microscope  objectives  are  fairly  standard  it  is  often  easier  to  specify  the  magnification  than  the  optical 
resolution  of  the  objective);  (2)  the  object  pixel  coverage,  expressed  in  pixels/mm,  that  gives  the 
number  of  linear  pixels  per  unit  distance  in  the  object  plane  to  provide  a good  image;  and  (3)  the 
number  of  pixels  required  to  make  a useful  image,  which  will  be  referred  to  as  the  required  pixels  along 
an  axis  or  the  horizontal-by- vertical  pixel  count  of  a two-dimensional  area. 

It  is  tempting  to  specify  the  camera  grayscale  response  and  capabilities,  the  camera  uniformity,  the 
camera  and  overall  system  linearity,  and  the  illumination  uniformity.  However,  it  is  difficult  to  write 
such  specifications  since  they  are  not  generally  known  by  the  manufacturers  of  the  ballistic  imagery 
equipment  and  did  not  enter  into  their  considerations  in  the  development  of  the  apparatus.  The 
apparatus  works,  and  the  component  parts  are,  for  the  most  part,  standard  off-the-shelf  items.  Further, 
such  specifications  are  not  readily  available  from  the  manufacturers  of  the  cameras  or  the  light  sources. 
One  alternative  is  to  provide  unambiguous  measurement  procedures  to  establish  these  parameters 
based  on  standardized  targets.  The  other  alternative  is  to  ignore  them  entirely,  essentially  assuming 
that  the  commonality  of  the  components  used,  combined  with  the  training  of  the  operators,  will  assure 
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Figure  1.  Optical  configuration  for  ballistics 
cartridge  imagery  used  in  this  document.  ( Axially 
symmetric  light  source  shown  in  partial  cross- 
section.) 
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sufficient  image  interoperability  as  far  as  these  parameters  are  concerned.  To  measure  these 
parameters  is  not  a simple  task  since  a number  of  systems  would  have  to  be  measured  under  a variety 
of  ambient  conditions  and  the  results  averaged.  If  it  should  be  determined  that  these  parameters  (the 
camera  and  illumination  characteristics)  are  essential  to  interoperability,  then  this  document  will  be 
appropriately  revised. 

There  are  more  critical  features  of  the  image  acquisition  process  that  do  need  to  be  specified,  and  these 
essential  features  are  addressed  in  this  document.  The  type  of  lighting  used  and  the  overall 
magnification  of  the  system  can  be  critical  to  obtaining  images  necessary  to  provide  interoperability. 
The  specifications  for  the  axially  symmetric  lighting  are  covered  in  Section  2. 1 and  for  the  oblique 
lighting  in  Section  2.2. 
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2.1  IBIS™  SYSTEM:  AXIALLY  SYMMETRIC  (ANNULAR)  LIGHTING 


Figure  2 shows  a fiber-optic  ring  light  as  the  only 
source  of  illumination.  Table  1 lists  the 
permissible  values  and  ranges  of  optical 
configurations  that  will  permit  proper  imaging  of 
cartridge  cases  using  an  axially  symmetric 
illumination  system.  Standard  microscope 
objectives  are  suggested  although  a zoom 
microscope  objective  can  also  be  used.  The  height 
of  the  ring  light  is  approximately  70  mm  ± 10  mm 
and  the  diameter  is  55  mm  ±10  mm. 


Figure  2.  Axially  symmetric  lighting  showing 
a fiber-optic  ring  light. 


Table  1 . Cartridge  Image  Requirements  for  Axially  symmetric  Illumination 

Cartridge 

Case  Object 

Microscope 

Objective 

Magnification 

Object  Pixel 
Coverage 
(pixels/mm) 

Required  Pixels 
(Horizontal  x 
Vertical) 

Breech  Face 

1 

104  ± 1 % 

480  x 480 

Firing  Pin  Impression 

1.5 

155  ± 1 % 

480  x 480 

Extractor  Marks 

Ejector  Marks 

1.5 

155  ±1  % 

480  x 480 

Chamber  Walls 

Rimfire 

2 

209  ± 1 % 

480  x 480 
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2.2  DRUGFIRE™  SYSTEM:  OBLIQUE  LIGHTING 


Figure  3 shows  the  configuration  for  oblique 
lighting  denoted  by  “O”  subscripts.  In  the  case  of 
imaging  with  oblique  light  there  may  be  a 
preferred  direction  with  which  the  object  must  be 
oriented.  Call  that  direction  the  x-axis.  For 
example,  linear  scratches  might  be  aligned  with  the 
x-axis  in  order  to  best  exploit  the  oblique  lighting. 
The  oblique  light  should  be  oriented  with  its  center 
above  the  y-axis  requiring  00  to  be  approximately 
90°.  The  angle  that  locates  the  center  of  the  cross- 
section  of  the  lamp  is  0q,  and  the  lamp  subtends 
an  angle  A0O  centered  about  0O.  The  extent  of 
rotational  coverage  of  the  lamp  will  be  denoted  by 
A(j>o-  The  lamp  should  be  shaded  so  that  the  lamp 
illumination  surface  is  not  directly  observable  by 
the  operator  under  normal  data-taking  conditions. 
There  are  no  requirements  for  the  reflectivity  of 
the  shade.  The  light  from  the  lamp  or  its  shade 
must  not  be  permitted  to  directly  illuminate  the 
objective  lens.  The  tilt  of  the  cartridge  surface 
toward  the  lamp  is  specified  by  A0. 

Table  2 and  Table  3 list  the  permissible  values  and 
ranges  of  optical  configurations  that  will  permit 
proper  imaging  of  cartridge  cases  for  the  oblique 
lighting  system.  These  are  intended  to  provide  the 
same  kind  of  flexibility  in  “high  and  tight”  lighting 
as  would  be  employed  by  a firearms  examiner. 


Figure  3.  Oblique  lighting  and  target- 
alignment  specification  variables. 
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Table  2.  Cartridge  Lighting  Configuration  Requirements 

Quantity 

Value  or  Range 

eO 

5°  to  45° 

A0O 

20°  ± 10° 

A<t>0 

45°  ± 10° 

A0 

0°  to  10° 

Table  3.  Cartridge  Image  Requirements  for  Oblique  Illumination 

Cartridge 

Case  Object 

Microscope 

Objective 

Magnification 

Minimum 
Object  Pixel 
Coverage 
(in  pixels/mm) 

Minimum  Required 
Pixels  Along  Axis 
of  Cartridge 

Breech  Face:  High 
Magnification 

3 

150 

Not  Applicable 

Breech  Face:  Medium 
Magnification 

2 

100 

Not  Applicable 

Breech  Face:  Low 
Magnification 

1.5 

75 

Not  Applicable 

Firing  Pin  Impression 

1.5 

150 

Not  Applicable 

Extractor  Marks 

1.5 

150 

Not  Applicable 

Ejector  Marks 

1.5 

150 

Not  Applicable 

Chamber  Walls 

1.5 

150 

450 

Rimfire 

1.5 

150 

Not  Applicable 
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3.0  DATA  FORMAT  SPECIFICATION 


This  section  shall  define  the  content,  format,  and  units  of  measurement  for  the  interchange  of  cartridge 
information  between  similar  or  dissimilar  systems.  Such  information  may  be  used  for  searching  and 
determining  correlations  with  other  cartridge  images  stored  in  the  master  files.  This  data  shall  consist 
of  a variety  of  mandatory  and  optional  items  including  transaction  information,  general  characteristic 
descriptors,  various  parameters,  and  compressed  digitized  images.  This  information  is  intended  for 
interchange  between  law  enforcement  agencies  for  identification  purposes. 

3.1  DATA  FORMAT  SELECTION 

Choosing  a data  format  specification  that  will  efficiently  and  properly  effect  the  interchange  of  data 
between  automated  ballistic  recognition  systems  requires  that  several  conditions  be  met:  (1)  Since 
image  quality  is  of  foremost  importance,  the  exchange  of  image  data  must  be  totally  lossless  to  enable 
accurate  database  correlation.  However,  lossy  image  data  may  be  tolerated  for  image  storage  and 
visual  image  comparison  purposes.  (2)  The  specification  must  be  capable  of  handling  and  processing 
information  expressed  as  eight-bit  grayscale  image  pixel  values.  (3)  There  must  be  provisions  for 
including  descriptive  textual  information  with  each  image.  This  information  shall  be  recorded  using  the 
seven-bit  American  National  Standard  Code  for  Information  Interchange  (ASCII)  as  described  in 
ANSI  X3.4  or  ISO  646-1983,  7-bit  Coded  Character  Set  for  Information  Interchange.2  (4)  In 
addition  to  dissimilar  ballistic  imaging  hardware,  the  specification  must  be  operational  across  multiple 
computer  platforms.  (5)  There  must  be  a capability  for  future  expansion. 

Several  common  file  formats  were  considered  that  could  be  used  for  the  exchange  of  ballistic  images 
and  textual  information  during  the  process  of  searching  for  a data  format  specification.  The  features 
and  capabilities  of  each  were  evaluated  in  light  of  the  requirements  specified  for  handling  transactions 
and  performing  correlations.  The  selection  process  was  also  based  on  the  desire  to  choose  a format 
that  was  recognized  as  a standard.  None  of  those  examined  was  found  to  exactly  meet  all  of  the 
criteria. 

Since  no  existing  standard  meets  all  of  the  stated  requirements,  a format  is  defined  in  this  report  that  is 
based  on  an  existing  and  recognized  forensic  information  interchange  standard,  namely,  Data  Format 
for  the  Interchange  of  Fingerprint  Information  (ANSI/NIST-CSL  1-1993).  This  standard  serves  as 
the  model  for  the  data  interchange  format  for  ballistic  information.  It  was  originally  developed  for  the 
interchange  of  fingerprint  information,  but  it  is  currently  being  expanded  to  include  other  types  of 
forensic  identification  information.  Federal,  state,  and  local  law  enforcement  administrations  are 
employing  this  method  as  a means  of  interchanging  forensic  data.  Use  of  this  framework  can  now 
provide  the  capability  of  incorporating  ballistics  information  into  a format  that  may  be  adopted  for  the 
interchange  of  many  types  of  forensic  data  relating  to  a specific  incident.  The  standard  has  provisions 
for  the  inclusion  of  transaction  information,  system  information,  general  characteristic  descriptors,  and 
images.  As  no  specific  compression  algorithm  is  mandated  by  the  standard,  both  uncompressed  and 
compressed  eight-bit  grayscale  data  can  be  encoded  and  exchanged  for  this  application.  The  standard 

2 Available  from  the  American  National  Standards  Institute,  11  West  42nd  Street,  New  York, 
NY 10036 
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can  also  be  expanded  for  the  handling  of  request  and  response  data.  Being  platform  independent  and 
simple  in  structure,  the  chosen  format  has  the  capabilities  to  handle  transaction  requests,  textual 
descriptive  data,  and  compressed  or  uncompressed  images.  This  approach  is  well  suited  for  the 
exchange  and  processing  of  BDFs. 


3.2  DATA  CONVENTIONS 


Scanned  grayscale  images  shall  consist  of  pixels,  each  of  which  shall  be  quantized  to  eight  bits  (256 
gray  levels)  and  shall  be  contained  in  a single  byte.  Each  grayscale  value  shall  be  expressed  as  an 
unsigned  byte.  A value  of  zero  shall  be  used  to  define  a black  pixel  and  a value  of  255  shall  be  used  to 
define  a white  pixel. 

A pair  of  reference  axes  shall  be  used  to  describe  the  position  of  each  pixel  within  an  image.  The  origin 
of  the  axes,  pixel  location  (0,0),  shall  be  located  at  the  upper  left-hand  comer  of  each  image.  The  x- 
coordinate  (horizontal)  position  shall  increase  positively  from  the  origin  to  the  right  side  of  the  image. 
The  y-coordinate  (vertical)  position  shall  increase  positively  from  the  origin  to  the  bottom  of  the  image. 
For  every  grayscale  image  scanned  and  formatted,  the  scan  sequence  of  the  exchanged  image  shall  be 
assumed  to  have  been  left  to  right  and  top  to  bottom. 


The  order  for  transmission  of  both  the  ASCII  text  and  the  binary  representations  of  bytes  shall  be  most 
significant  byte  first  and  least  significant  byte  last.  Within  a byte,  the  order  of  transmission  shall  be 
most  significant  bit  first  and  least  significant  bit  last.  Figure  4 illustrates  the  order  of  transmission  of  the 
bytes  and  bits  within  a file. 


MSB  LSB  MSB  LSB 

First  Byte  1 

Most  Significant  Byte  < ^Least  Significant  Byte 

Most  Significant  Byte  Within  a Block  Transmitted  First 


<r 


Most 

Significant 

Bit 


Byte  of  Data 


Least 

Significant 

Bit 


Most  Significant  Bit  Within  A Byte  Transmitted  First 


Figure  4.  Byte  & Bit  Ordering 
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3.3  IMAGE  DATA 


3.3.1  LOSSLESS  JPEG  COMPRESSION 

Processing  requirements  for  the  exchange  of  image  files  is  costly  both  in  terms  of  image  transmission 
time  and  storage  usage.  For  this  reason,  it  is  desirable  to  decrease  the  time  required  to  transmit  the 
data  and  the  amount  of  storage  needed  to  contain  the  images.  This  interchange  format  provides  for  the 
exchange  of  uncompressed  or  compressed  images.  By  employing  the  lossless  mode  of  the  JPEG3 
algorithm,  a compression  ratio  of  approximately  2: 1 can  be  achieved  without  any  loss  to  data  or  image 
quality.  Further,  the  JPEG  algorithm  also  can  be  used  in  the  lossy  baseline  mode  for  even  greater 
compression  for  image  storage  and  subsequent  visual  comparisons  of  images. 

3.3.2  JPEG  FILE  STRUCTURES 

Image  data  to  be  compressed  shall  be  compressed  in  accordance  with  the  JPEG  algorithm.  Data 
resulting  from  this  compression  technique  may  be  considered  as  a stream  of  marker  segments  or  data 
blocks.  Every  JPEG  interchange  file  begins  with  a Start  Of  Image  (SOI)  marker  code  segment 
(consisting  of  a unique  two-byte  marker  code),  followed  by  the  JPEG  encoded  image  with  associated 
tables  for  decoding,  and  ends  with  an  End  Of  Image  (EOI)  marker  segment  (consisting  of  a unique 
two-byte  marker  code). 

During  development  of  the  JPEG  interchange  format,  the  need  was  recognized  to  include  application- 
specific  information  in  the  JPEG  interchange  file.  This  need  was  fulfilled  by  the  JPEG  designers  who 
provided  application  marker  segments  (APPn)  for  the  interchange  of  such  information. 

A common  application  marker  segment  (APPO)  has  been  recognized  as  a wrapper  for  JPEG  encoded 
images.  The  JPEG  File  Interchange  Format  (JFIF)  Version  1 .02  will  be  used  for  the  exchange  of 
compressed  image  data.  Information  that  is  missing  from  the  JPEG  stream  that  may  be  required  to 
process  the  image  is  provided  by  this  marker  segment.  It  also  allows  other  applications  to  import 
JPEG  encoded  files.  The  JFIF'  is  a minimal  file  format  that  enables  JPEG  bitstreams  to  be  exchanged 
among  a wide  variety  of  platforms. 

The  JFIF'  marker  segment  is  entirely  compatible  with  the  standard  JPEG  interchange  format.  The  only 
requirement  is  the  inclusion  of  the  JFIF  APPO  marker  segment,  which  is  imbedded  in  the  compressed 
JPEG  interchange  file  immediately  following  the  SOI  marker. 


^ ISO  International  Standard  10918-1,  Information  Technology  - Digital  Compression  and  coding  of 
Continuous-Tone  Still  images  Part  1 : Requirements  and  Guidelines  (Commonly  referred  to  as  JPEG). 
Available  from  the  American  National  Standards  Institute,  1 1 West  42nd  Street,  New  York,  NY 
10036. 
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3.4  FILE  DESCRIPTION 


This  section  defines  the  composition  of  a BDF  to  be  exchanged  between  laboratory  systems.  Each 
BDF  shall  contain  one  or  more  logical  records.  Two  logical  records  are  defined  for  the  purpose  of 
exchanging  ballistics  information.  One  is  the  transaction  record  that  shall  contain  information 
pertaining  to  the  transaction  itself.  The  other  logical  record  contains  descriptive  textual  information, 
the  image  data,  or  both.  Descriptive  and  image  data  may  be  from  a specimen  submitted  for  correlation 
or  the  results  of  a correlation. 

3.4.1  TRANSACTION  RECORD 

The  transaction  shall  be  defined  by  a Type-1  record.  Its  presence  is  mandatory  and  shall  be  used  with 
each  transaction.  There  shall  be  one — and  only  one — transaction  record  in  a BDF.  It  shall  always  be 
the  first  record  exchanged  and  consists  entirely  of  ASCII  textual  data.  The  Type-1  record  shall  provide 
information  describing  type  and  use  of  transaction.  It  shall  also  include  a listing  of  each  record  present 
in  the  BDF  and  other  information  items. 

A series  of  tagged  fields  shall  be  used  to  provide  information  required  to  process  the  transaction.  The 
data  fields  in  this  record  shall  be  recorded  in  variable-length  ASCII  fields.  The  fields  contained  within 
the  record  shall  be  numerically  ordered  and  their  contents  shall  be  as  specified  by  this  report. 

3.4.2  IMAGE  RECORD 

The  image  record  shall  be  defined  as  a Type- 12  record.4  Depending  on  the  purpose  of  the  transaction, 
there  may  be  from  zero  to  any  number  of  these  image  records.  This  record  type  shall  be  used  to 
exchange  a combination  of  ASCII  and  binary  image  data  within  a single  logical  record  structure.  The 
Type- 12  record  shall  provide  general  characteristic  descriptors  and  up  to  one  scanned  image.  At  the 
beginning  of  the  record,  a series  of  tagged  fields  shall  provide  the  descriptor  information  associated 
with  the  binary  image  data  optionally  present  in  the  last  field  of  the  logical  record. 

The  data  fields  in  this  record  shall  be  recorded  in  variable-length  fields  using  ASCII  code.  The  fields 
contained  within  the  record  shall  be  numerically  ordered  and  their  contents  shall  be  as  specified  in  this 
report. 


4 The  record  type  numbers  and  field  numbers  within  each  record  type  may  not  always  be  sequential. 
Gaps  in  the  numbering  system  are  a result  of  harmonizing  this  report  with  the  fingerprint  interchange 
standard. 
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3.4.3  IMAGE  DESIGNATION  CHARACTER  (IDC) 


This  construct  shall  be  used  to  identify  and  link  together  multiple  scannings  of  the  same  view  of  a 
specimen.  For  example,  if  it  is  desired  to  use  different  illumination  levels  to  scan  and  include  two  or 
more  renditions  of  the  same  cartridge  case  in  a single  BDF,  this  construct  allows  the  receiving  system 
to  recognize  and  link  the  multiple  scannings.  The  IDC  properly  identifies  logical  records  that  pertain  to 
the  same  image. 

Each  Type- 12  record  in  a BDF  shall  include  an  IDC.  This  IDC  shall  be  used  to  relate  information 
items  in  the  file  contents  field  of  the  Type-1  record  to  each  Type- 12  record.  For  a BDF  containing 
general  characteristic  or  image  data,  the  value  of  the  IDC  shall  be  a sequentially  assigned  positive 
integer  starting  from  one  and  incremented  by  one.  For  transactions  that  are  limited  to  returning  or 
requesting  a list  of  specimen  identification  numbers,  the  IDC  shall  be  zero. 


3.5  RECORD  FORMAT 

For  both  types  of  logical  records,  several  information  fields  shall  be  present.  Data  entries  within 
information  fields  may  be  further  subdivided  into  information  items  that  are  used  to  convey  different 
aspects  of  the  data  contained  in  that  field.  In  addition,  certain  fields  may  contain  subfields  consisting  of 
multiple  entries  of  the  same  type  of  information. 

3.5.1  INFORMATION  SEPARATORS 

Although  flexible,  this  format  requires  a means  of  identifying  the  beginning  and  end  of  each  information 
field  and  each  piece  of  information  within  each  field. 

Mechanisms  for  delimiting  information  fields  within  a logical  record,  items  within  a field,  and  multiple 
occurrences  of  information  within  the  same  field  shall  be  implemented  by  use  of  four  ASCII 
information  separators.  These  characters,  defined  in  ANSI  X3.4,  shall  be  used  to  separate  and  qualify 
information  in  a logical  sense:  the  File  Separator  (FS)  character  shall  be  used  to  mark  the  end  of  a 
logical  record;  the  Group  Separator  (GS)  character  shall  be  used  to  delimit  fields;  the  Unit  Separator 
(US)  character  shall  be  used  to  delimit  information  items  within  a subfield;  and  the  Record  Separator 
(RS)  character  shall  delimit  multiple  occurrences  of  the  same  subfield.  Table  4 lists  these  ASCII 
separators,  their  hex  code  equivalents,  and  a description  of  their  use  within  this  document.  These 
separators  shall  be  in  addition  to  any  other  symbols,  punctuation,  or  delimiters  as  specified  in  this 
standard. 
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Table  4.  Information  Separators 

Ascn 

CHARACTER 

HEX 

CODE 

DESCRIPTION 

FS 

“1C” 

Terminates  BDF  logical  record 

GS 

“ID” 

Delimits  fields  within  the  BDF  logical  record 

RS 

“IE” 

Delimits  multiple  data  entries  (subfields)  of  an  information 
field 

US 

“IF’ 

Delimits  individual  information  items  of  the  field  or  subfield 

These  four  characters  shall  be  used  only  as  separators  of  data  items,  and  only  one  of  them  may  be  used 
between  any  two  data  items.  A US  character  cannot  immediately  precede  an  RS  character;  an  RS 
cannot  immediately  precede  a GS;  and  a GS  cannot  immediately  precede  and  FS  character.  The  FS 
character  separator  will  take  precedence  over  the  GS;  the  GS  over  the  RS;  and  the  RS  over  the  US. 
Annex  A illustrates  the  use  of  these  separator  characters. 

All  information  fields  used  in  the  BDF  logical  records  shall  be  numbered  in  accordance  with  the 
numbering  scheme  described  in  this  report.  The  format  of  each  field  shall  consist  of  a field  identifier 
number  followed  by  a colon  (:),  followed  by  the  information  item(s)  appropriate  to  that  field.  Field 
identifier  numbers  within  each  logical  record  shall  be  in  ascending  order.  Individual  information  items 
within  the  subfield  shall  be  separated  by  the  US  character.  Repeating  subfields  within  a field  shall  be 
separated  by  the  RS  character.  In  addition  to  the  field  identifying  number,  information  fields  shall  be 
separated  from  other  information  fields  by  the  GS  character.  Annex  A contains  an  example  of  the  use 
of  the  format,  which  illustrates  the  layout  for  both  logical  record  types. 

3.5.2  RECORD  LAYOUT 

For  each  record  type,  information  fields  that  are  used  shall  be  numbered  in  accordance  with  this  report. 
The  format  for  each  field  shall  consist  of  a field  identifier  number  followed  by  a colon  (:),  followed  by 
the  information  item(s)  appropriate  to  that  field.  The  field  numbers  shall  have  the  format  “l.XX”  for 
the  Type-1  record,  and  “12.XXX”  for  the  Type- 12  record.  The  “XX”  or  “XXX”  entry  shall  be  the 
assigned  field  number  within  that  record  type. 
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3.6  TYPE-1  TRANSACTION  RECORD 


The  purpose  of  this  logical  record  is  to  convey  information  pertaining  to  the  interchange  transaction 
itself.  Table  5 summarizes  the  fields  appearing  in  this  record.  For  each  field,  its  identifier,  condition 
code,  number,  and  description  are  listed.  Under  the  CONDITION  heading,  entries  identify  the 
mandatory  or  optional  nature  of  the  field.  An  entry  of ‘D”  signifies  that  the  field  is  required  for 
transactions  targeted  for  a DRUGFIRE  system.  An  entry  of  “I”  signifies  that  the  field  is  required  for 
transactions  targeted  for  an  IBIS  system.  An  entry  of  “O”  implies  the  field  is  optional  for  both. 


Table  5.  Transaction  Records  Fields 

IDEN- 

TIFIER 

CONDITION 

FIELD 

NUMBER 

FIELD  DESCRIPTION 

LEN 

D/I 

1.01 

Logical  Record  Length 

VER 

D/I 

1.02 

Version  Number 

CNT 

D/I 

1.03 

File  Content 

TOT 

D/I 

1.04 

Type  of  Transaction 

DAT 

D/I 

1.05 

Date  of  Transaction 

PRY 

O 

1.06 

Priority 

DLI 

D/I 

1.07 

Destination  Laboratory 

OLI 

D/I 

1.08 

Originating  Laboratory 

TCN 

D/I 

1.09 

Transaction  Control  Number  (Submitted) 

TRN 

D/I 

1.10 

Transaction  Response  Number  (Host) 

NUM 

D/I 

1.11 

Number  of  Matches  or  Images  Requested 

3.6.1  FIELD  1.01:  LOGICAL  RECORD  LENGTH  (LEN) 

This  mandatory  ASCII  field  shall  contain  the  total  count  of  the  number  of  bytes  in  this  Type- 1 logical 
record.  The  count  shall  include  every  character  of  every  field  contained  in  the  record  and  the 
information  separators.  This  field  is  terminated  by  the  GS  character. 

NOTE:  Although  it  may  not  always  be  explicitly  repeated  in  the  remainder  of  this  document,  use  of 
separator  characters  within  the  BDF  logical  records  will  always  be  observed.  Specific  information 
items  within  afield  or  subfield  shall  be  separated  by  the  US  character,  multiple  subfields  shall  be 
separated  by  the  RS  character,  and  fields  shall  be  separated  by  the  GS  character. 
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3.6.2  FIELD  1.02:  VERSION  NUMBER  (VER) 


This  mandatory  four-byte  ASCII  field  shall  be  used  to  specify  the  version  number  of  the 
implementation  creating  the  file.  The  most  significant  two  bytes  indicate  the  major  revision  and  the 
least  significant  two  bytes  the  minor  revision.  Version  1 .00  is  the  current  revision. 

3.6.3  FIELD  1.03:  FILE  CONTENT  (CNT) 

This  mandatory  field  shall  list  each  of  the  logical  records  in  the  BDF  by  record  type.  It  also  specifies 
the  order  in  which  the  remaining  logical  records  shall  appear  in  the  BDF.  Consisting  of  one  or  more 
subfields,  each  subfield  shall  contain  two  information  items  describing  a single  logical  record  found  in 
the  current  BDF.  The  subfields  shall  be  entered  in  the  same  order  in  which  the  logical  records  shall  be 
transmitted.  The  RS  separator  character  shall  be  entered  between  the  subfields. 

The  first  subfield  shall  relate  to  this  Type-1  transaction  record.  The  first  information  item  within  this 
subfield  shall  be  a “1,”  indicating  that  this  is  a Type-1  record  consisting  of  transaction  information. 
The  second  information  item  of  this  subfield  shall  be  the  number  of  the  Type- 12  records  following. 
This  number  is  also  equal  to  the  count  of  the  remaining  subfields  of  Field  1.03.  The  US  character 
separator  shall  be  entered  between  the  first  and  second  information  items. 

The  remaining  subfields  of  Field  1.03  shall  each  be  composed  of  two  information  items.  The  first 
information  item  shall  be  the  number  “12”  indicating  an  image  record.  The  second  information  item 
shall  be  the  IDC  associated  with  the  logical  record  pertaining  to  that  subfield.  The  IDC  shall  be  a 
positive  integer  greater  than  or  equal  to  zero.  The  US  character  shall  be  used  to  separate  the  two 
information  items.  The  uncompressed  or  JPEG  encoded  images  in  the  BDF  must  appear  in  the  same 
order  as  stated  in  this  field. 

3.6.4  FIELD  1.04:  TYPE  OF  TRANSACTION  (TOT) 

This  mandatory  field  shall  contain  an  identifier  designating  the  type  of  transaction  contained  in  the 
BDF.  An  entry  chosen  from  Table  6 shall  be  inserted  in  this  field  to  identify  the  subsequent  action  or 
processing  to  be  performed.  Multiple  transaction  codes  shall  require  the  use  of  multiple  Type- 12 
records. 
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Table  6.  Transaction  Codes 

TRANSACTION 

TRANSACTION  DESCRIPTION 

CODE 

CORGCD 

Correlate  Using  General  Characteristic  Descriptors 

CORIMG 

Correlate  Using  Descriptor  and  Image  Data 

SNDRES 

Send  Response  to  Submitter 

REQLIS 

Request  List  of  Image  Numbers 

SNDLIS 

Send  List  of  Numbers  for  Correlated  Matches 

REQIMG 

Request  One  or  More  Images 

SNDIMG 

Send  Requested  Images 

3.6.5  FIELD  1.05:  DATE  OF  TRANSACTION  (DAT) 

This  mandatory  field  shall  contain  the  date  that  the  transaction  was  initiated.  The  date  shall  appear  as 
eight  digits  in  the  format  CCYYMMDD.  The  CCYY  characters  shall  represent  the  year  of  the 
transaction;  the  MM  characters  shall  be  the  tens  and  units  values  of  the  month;  and  the  DD  characters 
shall  be  the  tens  and  units  values  of  the  day  in  the  month.  For  example,  19960315  represents  March 
15,  1996.  The  transaction  date  shall  not  be  later  than  the  current  date. 

3.6.6  FIELD  1.06:  PRIORITY  (PRY) 

When  this  field  is  used,  it  shall  contain  a single  information  character  to  designate  the  urgency  with 
which  a response  is  desired.  The  values  shall  range  from  1 through  4,  with  “1”  denoting  the  highest 
priority.  The  default  value  shall  be  “4”  if  no  value  is  indicated. 

3.6.7  FIELD  1.07:  DESTINATION  LABORATORY  IDENTIFIER  (DLI) 

This  mandatory  field  shall  contain  the  identifier  of  the  laboratory  designated  to  receive  the  transmission. 
The  size  and  data  content  of  this  field  shall  be  user-defined  and  in  accordance  with  the  receiving 
laboratory. 

3.6.8  FIELD  1.08:  ORIGINATING  LABORATORY  IDENTIFIER  (OLI) 

This  mandatory  field  shall  contain  the  identifier  of  the  laboratory  originating  the  transaction.  The  size 
and  data  content  of  this  field  shall  be  user-defined  and  in  accordance  with  the  laboratory  submitting  the 
transaction. 
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3.6.9  FIELD  1.09:  TRANSACTION  CONTROL  NUMBER  (TCN) 


This  mandatory  field  shall  contain  the  Transaction  Control  Number  as  assigned  by  the  originating 
laboratory.  A unique  control  number  shall  be  assigned  to  each  transaction.  This  field  is  intended  to 
track  the  transaction  to  be  processed.  The  specimen  identification  is  contained  in  the  Type- 12  record. 
For  any  transaction  that  requires  a response,  the  respondent  shall  refer  to  this  number  when 
communicating  with  the  originating  laboratory. 

3.6.10  FIELD  1.10:  TRANSACTION  RESPONSE  NUMBER  (TRN) 

This  is  a mandatory  field  when  used  by  a host  system  to  respond  to  a transaction  from  a remote  system. 
It  shall  contain  the  Transaction  Response  Number  as  assigned  by  the  host  system.  Results  of 
correlations  are  stored  using  this  number  as  a pointer.  This  field  is  intended  to  track  the  results  of  a 
submitted  transaction — not  to  identify  a particular  specimen  or  stored  image. 

3.6.11  FIELD1.11:  NUMBER  OF  MATCHES  OR  IMAGES  (NUM) 

This  mandatory  field  serves  two  purposes.  First,  it  can  contain  the  number  of  matches  resulting  from  a 
correlation.  Second,  it  can  contain  a count  of  the  number  of  images  to  be  downloaded.  This  count 
would  be  used  by  a host  system  to  download  a specific  number  of  images  from  a list  formed  as  a result 
of  a correlation. 


3.7  TYPE-12  TRANSACTION  RECORD 

This  record  type  is  used  to  provide  information  for  image  requests  submitted  to  a remote  host  system 
for  correlation,  or  to  request  one  or  more  specific  images  be  downloaded  from  a remote  host  system. 

It  is  also  used  by  the  remote  host  system  to  return  correlation  results  (an  image  or  list  of  probable 
candidates)  or  to  download  one  or  more  requested  images.  For  correlation  requests,  this  logical  record 
contains  the  required  general  characteristic  descriptor  information  in  addition  to  the  scanned  image  data 
from  the  cartridge.  When  used  by  the  host  system  to  return  a probable  candidate  image  or  a requested 
image,  the  general  characteristic  descriptors  and  image  data  previously  stored  on  the  host  system  will 
be  returned.  Each  Type- 12  logical  record  shall  contain  pixel  data  from  a single  image  or  no  pixel 
image  data.  Multiple  images  shall  require  multiple  Type- 12  logical  records. 

Table  7 summarizes  the  image  record  fields.  For  each  field,  the  identifier,  condition  code,  field 
number,  and  a brief  description  are  listed.  The  following  paragraphs  describe  the  data  contained  in  the 
fields  for  the  Type- 12  record.  Each  field  shall  begin  with  the  number  of  the  record  type  followed  by  a 
period,  followed  by  the  appropriate  three-character  field  number,  followed  by  a colon. 
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Table  7.  Image  Record  Fields 

IDENTIFIER 

CON- 

DITION 

FIELD 

NUMBER 

FIELD  DESCRIPTION 

LEN 

D/I 

12.001 

Logical  Record  Length 

IDC 

D/I 

12.002 

Image  Designation  Character 

TST 

D/I 

12.003 

Test  or  Evidence 

SSI 

D/I 

12.004 

Submitted  Specimen  Identification  Number 

HSI 

D/I 

12.005 

Host  Specimen  Identification  Numbers 

BIT 

D/I 

12.006 

Ballistic  Image  Type 

DTI 

D/l 

12.007 

Date  of  Incident 

OPI 

D 

12.008 

Operator  Identification 

ICS 

D/I 

12.009 

Image  Capture  System 

ITS 

D/I 

12.010 

Image  Target  System 

CAL 

D/I 

12.011 

Caliber  Description 

FAM 

D 

12.012 

Caliber  Family 

ISP 

D/l 

12.013 

Image  size  in  Pixels 

IPM 

O 

12.014 

Image  size  in  mm. 

GCA 

D/I 

12.015 

Grayscale  Compression  Algorithm  Used 

CLC 

D/I 

12.016 

Camera  Linearity  Correction 

COM 

O 

12.017 

Comment 

CARTRIDGE  CASE: 

BMT 

D 

12.020 

Breech  Face  Marking  Type 

XBP 

I 

12.021 

External  Breech  Face  Circle  Position 

IBP 

I 

12.022 

Internal  Breech  Face  Circle  Position 

FPI 

D 

12.023 

Firing  Pin  Impression  Shape 

FPM 

D 

12.024 

Firing  Pin  Impression  Marks  Descriptor 
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IDENTIFIER 

CON- 

DITION 

FIELD 

NUMBER 

FIELD  DESCRIPTION 

FDD 

D 

12.025 

Firing  Pin  Drag  Descriptor 

FPP 

I 

12.026 

Firing  Pin  Position 

EEL 

D 

12.027 

Ejector/Extractor  Locations 

EMP 

I 

12.028 

Ejector  Mark  Position 

ECP 

I 

12.029 

Ejector  Contour  Position 

RCP 

I 

12.030 

Rimfire  Contour  Position 

IMAGE  DATA: 

IMG 

D/I 

12.999 

Image  Data 

3.7.1  FIELD  12.01:  LOGICAL  RECORD  LENGTH  (LEN) 

This  mandatory  ASCII  field  shall  contain  the  total  count  of  the  number  of  bytes  in  this  Type-12  logical 
record.  This  count  shall  account  for  every  byte  of  every  field  (including  the  image  data)  contained  in 
the  record  and  the  information  separators.  The  GS  character  shall  separate  the  length  of  Field  1.01 
from  the  next  field. 

3.7.2  FIELD  12.002:  IMAGE  DESIGNATOR  CHARACTER  (IDC) 

This  mandatory  ASCII  field  shall  be  used  to  identify  the  image  data  contained  in  this  record.  The  IDC 
contained  in  this  field  shall  match  the  IDC  found  in  the  file  content  field  of  the  Type-1  record.  If  the 
transaction  is  a returned  or  submitted  list  of  specimen  identification  numbers,  then  the  IDC  shall  be 
zero. 

3.7.3  FIELD  12.003:  TEST  OR  EVIDENCE  (TST) 

This  mandatory  ASCII  field  identifies  the  specimen  as  either  test  or  evidentiary.  This  item  shall  contain 
either  “TEST”  or  “EVID”  to  indicate  the  nature  of  the  image.  This  field  shall  contain  a maximum  of 
one  entry. 
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3.7.4  FIELD  12.004:  SUBMITTED  SPECIMEN  IDENTIFICATION  (SSI) 


This  mandatory  field  shall  contain  the  identification  number  of  the  specimen  that  is  recognized  by  the 
submitting  laboratory.  The  content  and  format  of  this  field  shall  be  in  accordance  with  the  laboratory 
that  is  in  possession  of  the  specimen  and  is  submitting  the  query. 

3.7.5  FIELD  12.005:  HOST  SPECIMEN  IDENTIFICATION  NUMBERS  (HSI) 

This  field  shall  contain  a list  of  one  or  more  specimen  identification  numbers  belonging  to  and 
recognized  by  the  host  laboratory.  This  field  may  contain  the  image  identification  numbers  of  the 
images  owned  by  the  host  laboratory  obtained  from  a correlation  search.  It  can  also  be  used  by  a 
remote  laboratory  for  submitting  a request  to  download  one  or  more  images  from  the  host  laboratory. 
This  field  shall  consist  of  one  or  more  subfields,  each  subfield  containing  the  identification  of  a unique 
specimen  image  that  may  include  a case  number.  The  content  and  format  of  this  field  shall  be  in 
accordance  with  the  host  laboratory. 

3.7.6  FIELD  12.006:  BALLISTIC  IMAGE  TYPE  (BIT) 

This  mandatory  ASCII  field  contains  one  information  item.  It  is  intended  to  identify  the  type  of  ballistic 
image  or  specimen  description  contained  in  this  record.  This  item  shall  contain  one  entry  selected  from 
Table  8.  This  field  shall  contain  a maximum  of  one  entry. 


Table  8.  Image  Types 

IMAGE  CODE 

IMAGE  TYPE 

BRF 

Breech  Face 

FRP 

Firing  Pin 

EJM 

Ejector  Marks 

EXM 

Extractor  Marks 

RMF 

Rimfire 

CRT 

Cartridge  Case 

3.7.7  FIELD  12.007:  DATE  OF  INCIDENT  (DTI) 

This  field  shall  contain  the  date  that  the  incident  occurred.  The  date  shall  appear  as  eight  digits  in  the 
format  CCYYMMDD.  The  CCYY  shall  represent  the  year  of  the  transaction;  the  MM  shall  be  the 
value  of  the  month;  and  the  DD  the  day  of  the  month.  For  example,  19960229  represents  February  29, 
1996.  The  incident  date  shall  not  be  later  than  the  current  date. 
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3.7.8  FIELD  12.008:  OPERATOR  IDENTIFICATION  (OPI) 


This  ASCH  field  shall  contain  the  identity  of  the  operator  that  captured  the  image.  Its  content  and 
format  shall  be  determined  by  the  formatting  laboratory. 

3.7.9  FIELD  12.009:  IMAGE  CAPTURE  SYSTEM  (ICS) 

This  field  shall  contain  a description  of  the  system  that  captured  the  image.  It  can  consist  of  five 
information  items  separated  by  the  US  character.  The  first  item  is  mandatory  and  shall  contain 
“DRUG”  or  “IBIS”  to  indicate  the  manufacturer  of  the  capture  system.  The  remaining  items  are 
optional  and  can  be  put  in  any  order:  the  model  number;  the  version  of  the  image  capturing  software, 
the  computer  platform  to  which  the  acquisition  system  is  attached,  and  the  operating  system  installed 
on  the  platform. 

3.7.10  FIELD  12.010:  IMAGE  TARGET  SYSTEM  (ITS) 

This  field  shall  identify  the  target  system  for  which  the  image  was  captured.  It  shall  be  assumed  that 
the  parameters  and  settings  required  by  the  target  system  were  in  effect  at  the  time  of  image  capture. 
This  field  shall  consist  of  one  or  more  information  items.  The  first  item  shall  contain  ‘DRUG”  or 
“IBIS”  to  indicate  the  manufacturer  of  the  target  system.  An  optional  second  information  item  may  be 
present  to  convey  the  model  number  of  the  target  system. 

3.7.11  FIELD  12.011:  CALIBER  DESCRIPTION  (CAL) 

This  mandatory  field  shall  contain  the  specimen's  caliber  type.  An  entry  from  Table  9 shall  be  inserted 
in  this  field.  Classifications  not  found  in  Table  9 shall  be  encoded  as  two  information  fields  separated 
by  the  US  character  separator.  The  first  information  item  will  be  the  numeric  caliber  (approximate 
diameter).  The  caliber  will  normally  be  expressed  in  lOOths  of  an  inch.  If  the  caliber  is  stated  in 
millimeters,  the  number  of  millimeters  will  immediately  be  followed  by  “mm.”  The  second  information 
item  shall  contain  a common  qualifier  for  the  caliber  size.  For  example,  a 22  Winchester  American 
would  contain  “22”  as  the  first  information  item,  and  “Winchester  American”  or  ‘ WA”  as  the  second 
information  item.  Multiple  subfields  separated  by  the  RS  character  may  be  used  for  those  instances 
when  the  caliber  cannot  be  determined  with  certainty. 
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Table  9.  Common  Caliber  Types 

CALIBER  CODE 

DESCRIPTION 

22SH 

.22  Short 

22LR 

.22  Long  Rifle 

22WM 

.22  Winchester  Magnum  Rimfire 

223R 

.223  Remington  (5.56  x 45  mm) 

25AU 

.25  Automatic  (6.35  mm  Auto) 

30CA 

.30  Carbine  (7.62  x 33  mm) 

3006 

.30-06  Springfield  (7.62  x 33  mm) 

3030 

.30-.30  Winchester  (7.62  x 63  mm) 

308W 

.308  Winchester  (7.62  x 51  mm  NATO) 

762R 

7.62  x 39  mm  (M43)  Russian 

32AU 

.32  Auto  (7.65  x 17  Auto) 

32SW 

.32  Smith  & Wesson 

32SL 

.32  Smith  & Wesson  Long  (CF) 

357M 

.357  Magnum 

38AU 

.38  Auto 

38SW 

.38  Smith  & Wesson 

38SP 

.38  Special 

380A 

.380  Auto  (9  mm  Browning  Short) 

9LUG 

9 mm  Parabellum  (LUGER) 

10AU 

10  mm  Auto 

40SW 

.40  Smith  & Wesson 

44RM 

.44  Remington  Magnum 

44SS 

.44  Smith  & Wesson 

45  AU 

.45  Auto 

UNKN 

Unknown/Unable  to  Determine 
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3.7.12  FIELD  12.012:  CALIBER  FAMILY  (FAM) 


This  optional  field  shall  contain  the  caliber  family  of  the  specimen.  This  field  shall  consist  of  a single 
entry  from  Table  10. 


Table  10.  Caliber  Families 

FAMILY  CODE 

DESCRIPTION 

CL14 

40  Caliber/10  mm  Family 

CL30 

30  Caliber/Family 

CL38 

38  Caliber/9  mm  Family 

CL44 

44  Caliber  Family 

CL32 

32  Caliber  Family 

CL45 

45  Caliber  Family 

CL22 

22  Caliber  Family 

CL2L 

22  SH/L  Caliber  Family 

CL2A 

25  AU  Caliber  Family 

CL9M 

9MAK  Caliber  Family 

3.7.13  FIELD  12.013:  IMAGE  SIZE  IN  PIXELS  (ISP) 

This  field  shall  contain  two  information  items  separated  by  the  US  character  describing  the  image  area 
contained  in  the  BDF.  The  first  entry  shall  be  the  number  of  pixels  in  a horizontal  line;  the  second  entry 
shall  be  the  number  of  lines  of  pixels  contained  in  the  image. 

3.7.14  FIELD  12.014:  IMAGE  SIZE  IN  MILLIMETERS  (ISM) 

This  field  is  necessary  if  the  horizontal  and  vertical  resolutions  were  not  provided  in  the  JF1F  APPO.  If 
present,  this  field  shall  contain  two  information  items  separated  by  the  US  character.  The  first  entry 
shall  be  the  horizontal  dimension  of  the  image  in  millimeters;  the  second  entry  is  the  vertical  dimension 
of  the  image  in  millimeters. 

3.7.15  FIELD  12.015:  GRAYSCALE  COMPRESSION  ALGORITHM  (GCA) 

This  mandatory  ASCII  field  is  used  to  specify  the  algorithm  used  to  compress  the  image.  An  entry  of 
“NONE”  shall  be  used  to  indicate  that  the  image  data  is  in  an  uncompressed  form;  an  entry  of 
“JPEGB”  indicates  that  lossy  baseline  JPEG  was  used  to  compress  the  image;  and  an  entry  of 
“JPEGL”  identifies  the  compression  algorithm  as  lossless  JPEG. 
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3.7.16  FIELD  12.016:  CAMERA  LINEARITY  CORRECTION  (CLC) 


The  entry  in  this  field  shall  be  used  to  account  for  any  non-linearity  in  the  image  capturing  system.  This 
non-linear  dependence  is  often  called  the  gamma  correction.  It  will  be  in  the  range  of  0.00  to  2.99.  If 
the  gamma  correction  is  unknown,  a value  of  0.00  is  required. 

3.7.17  FIELD  12.017:  COMMENT  (COM) 

The  optional  field  can  be  used  to  convey  comments  regarding  the  transaction.  It  contains  one  or  more 
free-form  textual  comments  separated  by  the  RS  character. 

3.7.18  FIELD  12.020  BREECH  FACE  MARKINGS  TYPE  (BMT) 

This  field  shall  identify  the  pattern  of  the  markings  on  the  breech  face.  An  appropriate  entry  chosen 
from  Table  1 1 shall  be  contained  in  this  field. 


Table  11.  Breech  Face  Markings 

BMT  CODE 

TYPE  OF  MARKING 

S 

Smooth  (No  Traces) 

C 

Concentric  Circles  or  Spirals  Around  Center 

P 

Parallel  (Any  Direction) 

X 

Cross-Hatched 

G 

Granular 

A 

Arcs 

O 

Other 

U 

Unknown/Unable  to  Determine 

3.7.19  FIELD  12.021:  EXTERNAL  BREECH  FACE  CIRCLE  POSITION  (XBP) 

This  field  shall  consist  of  three  information  items,  separated  by  the  US  character.  The  first  item  shall  be 
the  horizontal  pixel  position  of  the  center  of  the  circle  positioned  around  the  external  limit  of  the  breech 
face  area.  The  second  item  shall  be  the  corresponding  vertical  position.  The  third  item  shall  be  the 
radius  of  the  circle  expressed  as  an  integer  number  of  pixels. 

3.7.20  FIELD  12.022:  INTERNAL  BREECH  FACE  CIRCLE  POSITION  (IBP) 

This  field  shall  consist  of  three  information  items,  separated  by  the  US  character.  The  first  item  shall  be 
the  horizontal  pixel  position  of  the  center  of  the  circle  positioned  around  the  internal  limit  of  the  breech 
face  area.  The  second  item  shall  be  the  corresponding  vertical  position.  The  third  item  shall  be  the 
radius  of  the  circle  expressed  as  an  integer  number  of  pixels. 
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3.7.21  FIELD  12.023:  FIRING  PIN  IMPRESSION  SHAPE  (FPI) 


This  field  shall  identify  the  shape  of  the  firing  pin  impression.  An  entry  chosen  from  Table  12  shall  be 
entered  in  this  field.  Multiple  entries  separated  by  the  RS  character  may  be  used  to  correlate  on  more 
than  one  shape. 


Table  12.  Firing  Pin  Impressions 

FPI  CODE 

FIRING  PIN  IMPRESSION  SHAPE 

C 

Circular  (Flat  Base) 

H 

Hemispherical 

R 

Rectangular  (Flat  Base) 

E 

Elliptical  (Similar  to  those  Produced  by  Glock  & S.W.D.  Pistols) 

O 

Other/Irregular 

U 

Unknown/  Unable  to  Determine 

3.7.22  FIELD  12.024:  FIRING  PIN  IMPRESSION  MARKS  DESCRIPTOR  (FPM) 

This  field  shall  contain  a descriptor  of  the  firing  pin  impression  marks.  An  appropriate  entry  chosen 
from  Table  13  shall  be  contained  in  this  field. 


Table  13.  Firing  Pin  Impression  Marks  Descriptor 

BMT  CODE 

TYPE  OF  MARKING 

S 

Smooth  (No  Traces) 

C 

Concentric  Circles  or  Spirals  Around  Center 

P 

Parallel  (Any  Direction) 

X 

Cross-Hatched 

G 

Granular 

A 

Arcs 

O 

Other 

U 

Unknown/Unable  to  Determine 
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3.7.23  FIELD  12.025:  FIRING  PIN  DRAG  DESCRIPTOR  (FDD) 


This  field  shall  contain  a descriptor  of  the  firing  pin  drag  mark.  An  entry  chosen  from  Table  14  shall  be 
entered  in  this  field. 


Table  14.  Firing  Pin  Drag  Descriptor 

DRAG  CODE 

DESCRIPTION 

D 

Drag  Mark  out  of  Firing  Pin  Impression 

N 

No  Pronounced  Firing  Pin  Drag 

U 

Unable  to  Determine 

3.7.24  FIELD  12.026:  FIRING  PIN  POSITION  (FPP) 

This  field  shall  consists  of  three  information  items,  separated  by  the  US  character.  The  first  item  shall 
be  the  horizontal  pixel  position  of  the  center  of  the  circle  positioned  around  the  external  limit  of  the 
firing  pin  area.  The  second  item  shall  be  the  corresponding  vertical  position.  The  third  item  shall  be 
the  radius  of  the  circle  expressed  as  an  integer  number  of  pixels. 

3.7.25  FIELD  12.027:  EXTRACTOR/EJECTOR  LOCATIONS  (EEL) 

This  field  shall  contain  the  positions  of  all  extractor  and  ejector  marks  present  in  terms  of  hours  on  a 
clock  face.  Marks  falling  between  clock  positions  shall  be  coded  according  to  the  nearest  hour 
position.  If  in  doubt,  code  according  to  the  next  higher  value.  If  the  chamber  is  cut  out  for  the 
extractor,  a “C”  shall  be  immediately  (without  a space)  appended  to  the  clock  position.  The  RS 
separator  character  shall  be  used  between  multiple  entries. 

3.7.26  FIELD  12.028:  EJECTOR  MARK  POSITION  (EMP) 

This  field  shall  consist  of  three  information  items,  separated  by  the  US  character.  The  first  item  shall  be 
the  horizontal  pixel  position  of  the  center  of  a circle  around  the  external  limit  of  the  cartridge-case  base. 
The  second  item  shall  be  the  corresponding  vertical  position.  The  third  item  shall  be  the  radius  of  the 
circle  expressed  as  an  integer  number  of  pixels. 

3.7.27  FIELD  12.029:  EJECTOR  CONTOUR  POSITION  (ECP) 

This  field  shall  contain  the  coordinates  of  the  contour  of  the  geometric  delimiter  of  the  ejector  mark.  A 
series  of  imaginary  intersecting  lines  forming  a polygon  will  be  constructed  over  the  ejector  mark  to 
approximate  its  general  shape.  This  polygon  will  usually  consists  of  4 to  10  sides.  The  horizontal  and 
vertical  pixel  positions  for  each  of  the  vertices  of  the  polygon  shall  be  recorded  as  a series  of  repeating 
subfields.  The  first  information  item  of  the  each  subfield  shall  contain  the  horizontal  position  of  a 
vertex  and  the  second  item  shall  contain  the  vertical  position  of  the  vertex. 
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3.7.28  FIELD  12.030:  RIMFIRE  CONTOUR  POSITION  (RCP) 


This  field  shall  contain  the  coordinates  of  the  contour  of  the  geometric  delimiter  of  a rimfire  image.  A 
series  of  imaginary  intersecting  lines  forming  a polygon  will  be  constructed  over  the  rimfire  to 
approximate  its  general  shape.  This  polygon  will  usually  consist  of  4 to  10  sides.  The  horizontal  and 
vertical  pixel  positions  for  each  of  the  vertices  of  the  polygon  shall  be  recorded  as  a series  of  repeating 
subfields.  The  first  information  item  of  the  each  subfield  shall  contain  the  horizontal  position  of  a 
vertex,  and  the  second  item  shall  contain  the  vertical  position  of  the  vertex. 

3.7.29  FIELD  12.999:  IMAGE  DATA  (IMG) 

This  field  is  used  to  submit  an  image  to  a remote  host  system  for  correlation  or  to  return  an  image  that 
results  from  either  a successful  correlation  or  a laboratory's  request  for  an  image.  It  shall  contain  the 
image  data  from  a cartridge  case.  It  may  be  compressed  or  uncompressed  as  specified  by  the  GCA 
entry.  If  the  image  data  is  compressed,  it  shall  be  encoded  in  accordance  with  the  JPEG  standard  for 
the  lossless  or  baseline  modes  of  operation.  JPEG  files  shall  contain  the  JFIF  APPO  marker  segment  as 
described  in  the  JFIF  APPO  Marker  Segment  Section  3.9  of  this  document. 


3.8  END  OF  TYPE-12  LOGICAL  RECORD 

For  the  sake  of  consistency,  immediately  following  the  last  byte  of  textual  or  image  information  in  the 
Type-12  record,  an  FS  character  shall  be  used  to  separate  logical  records.  By  use  of  this  method 
several  imaged  cartridge  areas  can  be  contained  in  a BDF. 


3.9  JFIF  APPO  MARKER  SEGMENT 

In  the  encoded  JPEG  file  the  JFIF  APPO  marker  code  is  present  immediately  after  the  SOI  marker  to 
identify  the  presence  of  the  JFIF  APPO  segment.  It  is  identified  by  the  zero  terminated  string  “JFIF.” 
Information  that  is  missing  from  the  JPEG  stream  that  may  be  required  to  process  the  image  is 
provided  by  this  marker  segment. 

Table  15  summarizes  the  fields  required  for  the  JFIF  APPO  marker  segment.  The  contents  and  order  of 
each  item  or  field  must  appear  in  the  interchange  file  as  listed  in  Table  15.  The  following  paragraphs 
provide  additional  information  for  each  of  the  APPO  fields. 
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Table  15.  JFTF  Marker  Segment  Fields 

FIELD 

LENGTH 

(BYTES) 

HEXCODE 

SOI 

2 

XFFD8' 

APPO 

2 

XFFEO' 

Length 

2 

X'0010' 

Identifier 

5 

X'4A46494600' 

Version 

2 

X'0102' 

Units 

1 

X'Oz' 

Xdensity 

2 

X'xxxx' 

Ydensity 

2 

X'yyyy' 

Xthumbnail 

1 

X'00' 

Ythumbnail 

1 

X’00’ 

3.9.1  SOI 

The  Start  Of  Image  (SOI)  marker  is  not  part  of  the  JFTF  segment.  It  is  present  in  Table  15  for  the  sole 
purpose  of  indicating  the  beginning  of  the  JPEG  file. 

3.9.2  APPO 

Every  application  marker  segment  begins  with  a two-byte  hex  code.  The  JHF  format  uses  the  APPO 
code  as  the  application  marker  code.  This  marker  code  must  immediately  follow  the  SOI  marker  code. 

3.9.3  LENGTH 

The  number  contained  in  this  field  represents  the  total  APPO  segment  byte  count,  including  the  byte 
count  value  (2  bytes),  but  excluding  the  APPO  marker  code.  For  the  ballistic  file  application,  this  field 
shall  always  have  a value  of  16  (decimal). 

3.9.4  IDENTIFIER 

The  characters  contained  in  this  field,  “JFTF”  terminated  by  a null  character  (00),  uniquely  identify  this 
marker  segment  as  one  complying  with  the  JFTF  specification. 
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3.9.5  VERSION 


This  is  the  level  of  the  JFIF  specification  implemented.  The  most  significant  byte  indicates  the  major 
revision  and  the  least  significant  byte  the  minor  revision.  Version  1.02  is  the  current  released  revision. 

3.9.6  UNITS 

This  field  specifies  the  units  used  for  scanning  resolution.  The  value  of  z may  be  “0,”  “1,”  or  “2.”  A 
value  of  “1”  indicates  that  the  Xdensity  and  Ydensity  fields  are  in  terms  of  dots  per  inch;  a value  of 
“2”  indicates  dots  per  centimeter.  A value  of  “0”  indicates  that  there  is  no  unit  of  measurement  and 
that  Xdensity/Y density  quotient  results  in  the  pixel  aspect  ratio  rather  than  image  resolution.  As  non- 
square pixels  are  discouraged  for  portability  reasons,  the  Xdensity  and  Ydensity  values  should  normally 
equal  “1”  when  the  Units  field  is  “0.” 

3.9.7  XDENSITY 

This  field  is  used  to  specify  the  horizontal  resolution  of  the  image  if  the  Units  field  contains  a “1”  or  a 
“2.”  Otherwise,  it  indicates  the  horizontal  component  of  the  pixel  aspect  ratio. 

3.9.8  YDENSITY 

This  field  is  used  to  specify  the  vertical  resolution  of  the  image  if  the  Units  field  contains  a “1”  or  a “2.” 
Otherwise,  it  indicates  the  vertical  component  of  the  pixel  aspect  ratio. 

3.9.9  XTHUMBNAIL 

This  field  gives  the  horizontal  dimension  of  the  thumbnail  image5  included  in  this  JFIF  APPO.  This 
presence  of  this  field  is  mandatory  for  compatibility  with  previous  versions  of  the  JFIF’.  Its  value  shall 
be  set  to  X“00.” 

3.9.10  YTHUMBNAEL 

This  field  gives  the  vertical  dimension  of  the  thumbnail  image  included  in  this  JFIF  APPO.  This 
presence  of  this  field  is  mandatory  for  compatibility  with  previous  versions  of  the  JFIF.  Its  value  shall 
be  set  to  X“00.” 


5 Unless  there  is  an  acknowledged  need  for  the  use  of  thumbnail  images,  no  considerations  will  be 
given  to  them  in  this  report.  If  a need  is  identified,  then  provisions  can  be  considered  for  the  inclusion 
of  thumbnail  images. 


32 


4.  MINIMUM  INTEROPERABILITY 


This  section  is  intended  to  establish  the  framework  for  determining  a minimal  level  of  interoperability 
between  the  DRUGFTRE  and  IBIS  ballistic  identification  systems  with  respect  to  electronic  exchange 
of  data.  Simply  stated,  basic  interoperability  can  be  shown  to  exist  if  specimen  images  captured  by 
either  system  can  be  searched  against  the  other  system  and  result  in  successful  correlations.  For 
purposes  of  this  report,  minimal  interoperability  requires  that  both  systems  can  acquire  images  in  the 
style  of  the  dissimilar  system,  electronically  exchange  the  images,  perform  correlations  using  such 
images  from  the  dissimilar  system,  and  return  a limited  list  or  image(s)  of  candidate  identifications.  In 
this  first  report,  the  details  of  networking  or  the  protocols  used  to  exchange  data  will  not  be  addressed. 


4.1  TRANSACTION  CAPABILITIES 

Interoperability  requires  that  transactions  from  one  system  can  be  submitted  to  the  dissimilar  system 
and  that  useful  and  accurate  results  can  be  returned  in  response  to  these  requests.  To  provide 
interoperability,  both  systems  must  be  capable  of  formulating  and  processing  each  of  the  transactions 
listed  in  Table  6.  These  transactions  are  intended  to  illustrate  a minimum  functionality  for 
interoperability  between  dissimilar  systems.  All  the  information  that  is  needed  to  process  these 
transactions  shall  be  contained  in  the  transmitted  BDF.  Section  3 of  this  report  details  the  format  for 
the  required  records,  fields,  and  information  items  that  make  up  the  BDF.  The  list  of  transactions  are 
not  necessarily  all-inclusive  and  may  need  to  be  enhanced  in  a networking  environment.  The  following 
paragraphs  are  descriptions  of  each  of  these  basic  transactions. 

4.1.1  CORGCD:  CORRELATE  USING  DESCRIPTORS 

This  Type  Of  Transaction  (TOT)  is  used  by  a laboratory  to  submit  a request  to  a remote  host  system 
for  correlation  based  on  the  general  characteristic  descriptors  such  as  the  caliber  and  firing  pin 
impression  shape.  As  no  correlation  of  image  data  will  be  performed,  there  is  no  need  to  include  the 
specimen's  image  data  in  the  transaction.  The  purpose  of  this  TOT  is  to  filter  or  limit  the  host  system's 
database  search  area  to  a reasonable  number  of  candidates  for  which  image  correlations  must  be 
performed. 

The  submitter  shall  formulate  a BDF  containing  a Type-1  record  identifying  the  transaction  as  a 
“CORGCD”  and  one  Type- 12  record.  The  Type-12  record  shall  contain  the  required  general 
information  regarding  the  specimen  and  the  general  characteristic  descriptor  data.  After  completion  of 
this  correlation,  the  host  system  will  formulate  a BDF  to  be  returned  to  the  submitter.  The  BDF  will  be 
a single  Type-1  record  consisting  of  a SNDRES  transaction  type,  the  submitter's  TCN,  the  host's 
TRN,  and  the  number  of  correlated  matches  found. 
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4.1.2  CORIMG:  CORRELATE  USING  DESCRIPTORS  & IMAGE  DATA 


This  TOT  is  designed  to  submit  an  image  of  a specimen  to  a remote  host  for  correlation.  Either  the 
specimen's  general  characteristic  descriptor  data  or  the  results  of  a previously  submitted  CORGCD 
transaction  should  be  used  to  limit  the  number  of  image  correlations  that  must  be  performed. 

The  submitter  shall  formulate  a BDF  containing  a Type-1  record  identifying  this  as  a “CORIMG” 
transaction,  and  a Type- 12  record.  The  Type- 12  record  will  contain  the  required  general  information 
regarding  the  specimen,  the  general  characteristic  descriptor  data,  and  the  image  data  (field  12.999). 
The  TRN  containing  the  results  from  a previous  CORGCD  correlation  may  be  used  to  eliminate  a 
second  correlation  based  on  the  general  characteristic  descriptors.  The  image  data  submitted  will  have 
been  acquired  in  accordance  with  the  specifications  stated  in  Section  2.  Examples  of  uncompressed 
images  and  compressed  images  using  both  lossless  and  lossy  data  shall  be  used. 

After  completion  of  this  correlation,  the  host  system  will  formulate  a BDF  to  be  returned  to  the 
submitter.  The  BDF  will  be  a single  Type-1  record  consisting  of  a SNDRES  transaction  type,  the 
submitter's  TCN,  the  host's  TRN,  and  the  number  of  matches  found.  An  ordered  list  of  matches 
associated  with  the  correlation,  together  with  the  scores,  will  be  retained  by  the  host  system.  This 
information  is  accessible  to  the  laboratory  that  submitted  the  correlation  by  reference  to  the  TRN 
associated  with  the  correlation. 

4.1.3  SNDRES:  SEND  RESPONSE  TO  SUBMITTER 

This  TOT  is  used  by  the  host  system  to  send  a response  back  to  the  submitter  of  a correlation  request. 
The  BDF  constructed  by  the  host  will  consist  of  a Type-1  record  containing  the  submitter's  TCN  and 
the  host's  TRN  and  the  number  of  candidate  matches  found. 

4.1.4  REQLIS:  REQUEST  LIST  OF  IMAGE  NUMBERS 

This  transaction  is  used  to  request  the  list  of  identifying  numbers  of  matches  resulting  from  a previous 
CORGCD  or  CORIMG  transaction.  In  a Type-1  record,  the  requester  shall  enter  their  TCN  and  the 
host  system's  TRN  that  can  be  linked  to  a previous  correlation  transaction. 

4.1.5  SNDLIS:  TRANSMISSION  OF  LIST  OF  CORRELATED  IMAGES 

This  transaction,  used  by  a remote  host,  is  the  response  to  the  REQLIS  transaction.  The  BDF  for  this 
transaction  will  contain  a Type-1  record  and  a Type- 12  record.  The  identification  number  of  the 
specimen  previously  submitted  for  descriptor  or  image  correlation  shall  be  contained  in  field  12.004. 
The  identification  number(s)  of  the  probable  correlations  shall  be  contained  in  field  12.005.  If  no 
correlations  were  determined,  this  field  shall  contain  “NONE.” 
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4.1.6  REQIMG:  REQUEST  IMAGE(S) 


This  transaction  is  intended  to  be  used  by  a laboratory  to  request  one  or  more  images  from  a host 
system.  The  BDF  for  this  transaction  will  contain  a Type-1  and  a Type- 12  logical  record.  Field  four  of 
the  Type- 12  record  shall  contain  the  host  system's  identifying  number(s)  of  the  specimen  image(s) 
requested.  The  requester  is  not  required  to  format  any  field  that  is  above  12.005. 

Alternatively,  if  the  images  requested  are  the  results  of  a previous  correlation,  the  requester  may  enter 
the  host's  TRN  for  that  correlation  together  with  the  number  of  images  requested.  This  eliminates  the 
need  for  the  Type- 12  record. 

4.1.7  SNDIMG:  TRANSMISSION  OF  REQUESTED  IMAGE(S) 

This  transaction  is  the  response  to  a REQIMG  request.  The  BDF  will  contain  a single  Type-1  record 
and  a Type- 12  record  for  each  image  that  was  requested.  The  properly  formatted  image  data  shall  be 
contained  in  field  12.999.  The  identification  number  of  the  submitted  image  shall  be  contained  in  field 
12.004.  The  host's  identification  number  for  the  correlated  image  will  be  contained  in  field  12.005  of 
the  Type-12  record.  If  no  image  exists  for  the  requested  number,  field  12.005  shall  contain  “NONE.” 


4.2  NETWORKING 

To  provide  interoperability,  both  systems  must  be  able  to  transmit  and  accept  BDFs,  process  the 
required  transactions,  and  return  the  results  electronically.  Initially,  a low-level  form  of  electronic 
interchange,  such  as  a dialup  modem,  shall  be  used  for  communication  purposes.  Images  acquired 
from  one  system  in  accordance  with  Section  2 and  formatted  for  data  exchange  in  accordance  with 
Section  3 shall  be  transmitted  to  the  dissimilar  host  system.  These  images  shall  be  capable  of  being 
searched  and  correlated  against  a dissimilar  host  system's  database.  The  communication  packages  used 
on  both  systems  must  not  be  proprietary  to  either  system.  Different  packages  can  be  used  on  both 
systems,  but  they  are  required  to  interact  with  each  other  and  they  both  must  be  commercially  available 
off-the-shelf. 
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4.3  NETWORKING  RECOMMENDATION 


To  satisfy  the  minimal  interoperability  requirements  as  outlined  in  this  report,  a dialup  modem  can  be 
used  for  the  physical  exchange  of  data.  However,  this  method  of  communication  should  not  be 
considered  as  an  acceptable  standard  operating  procedure  for  production  purposes. 

Once  it  has  been  established  that  minimal  interoperability,  as  regards  searching  and  image  correlation, 
exists  between  the  dissimilar  systems,  the  focus  should  be  directed  toward  interoperability  solutions  in  a 
"lights  out"  environment.  Specifically,  this  requires  that  images  can  be  captured  and  transactions 
exchanged  and  processed  by  dissimilar  systems  in  an  asynchronous  manner  without  the  need  for  human 
intervention.  Although  not  part  of  the  agreements  reached  during  the  January  meeting  held  at  NIST, 
all  parties  should  develop  their  systems  in  such  a way  that  does  not  prohibit  “lights  out”  operation. 
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ANNEX A 


AN  EXAMPLE  OF  THE  USE  OF  THE  SPECIFICATION 


This  annex  is  an  example  of  the  transactions  that  might  occur  between  a remote  laboratory  requesting 
a correlation  of  an  evidence  against  a host  system’s  database.  The  transactions  are  a series  of  requests 
and  responses  between  the  remote  laboratory  and  the  host  system.  The  data  illustrated  is  fictional. 

The  transactions  and  data  entries  are  present  only  to  give  an  example  of  the  appearance  of  data 
formatted  according  to  this  specification.  JPEG  lossless  mode  was  used  to  compress  the  image  data 
with  a resulting  compression  ratio  of  1.8: 1,  which  includes  the  required  JPEG  tables  and  formatting. 


TRANSACTION  1:  Remote  laboratory  to  host  system. 

The  remote  laboratory  initiates  this  transaction,  which  contains  a Type  1 and  Type  12  record.  The 
host  system  is  requested  to  search  its  database  for  correlations  using  the  General  Characteristic 
Descriptors  (GCD)  of  a breech  face.  The  host  system  should  then  perform  automatic  correlations 
between  the  submitted  image  and  the  results  of  the  GCD  search.  (These  two  operations  could  also 
have  been  submitted  as  two  separate  transactions.) 


TYPE-1  RECORD 

* LENGTH  (LEN) 

* VERSION  (VER) 

* CONTENT  (CNT) 

* TYPE  OF  TRANSACTION  (TOT) 

* DATE  (DAT) 

PRIORITY  (PRY) 

* DESTINATION  AGENCY  IDENTIFIER  (DAI) 

* ORIGINATING  AGENCY  IDENTIFIER  (ORI) 

* TRANSACTION  CONTROL  NUMBER  (TCN) 


1.01:117  I 
1.02:0100 1 
1.03:1  s 1 s 12  s 01  I 
1.04:CORIMG  s 
1.05:19960530 1 
1.06:4  I 

1 .07  :DCFBIOOGUN5  Y I 
1.08:RVATF1 1GUN6Z  s 
1. 09:234567 AB  f 
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TYPE-12  RECORD 


* LENGTH  (LEN) 

* IMAGE  DESIGNATION  CHARACTER  (IDC) 

* TEST  OR  EVIDENCE  (TST) 

* SUBMITTED  SPECIMEN  ID  (SSI) 

* BALLISTIC  IMAGE  TYPE  (BIT) 

* DATE  OF  INCIDENT  (DTI) 

* OPERATOR  IDENTIFICATION  (OPI) 

* IMAGE  CAPTURE  SYSTEM  (ICS) 

* IMAGE  TARGET  SYSTEM  (ITS) 

* CALIBER  DESCRIPTION  (CAL) 

* IMAGE  SIZE  IN  PIXELS  (ISP) 

* IMAGE  SIZE  IN  MILLIMETERS  (ISM) 

* GRAYSCALE  COMPRESSION  ALGORITHM  (GCA) 

* CAMERA  LINEARITY  CORRECTION  (CLC) 

* BREECH  FACE  MARKING  TYPE  (BMT) 

* EXTERNAL  BREECH  FACE 

CIRCLE  POSITION  (XBP) 

* INTERNAL  BREECH  FACE  CIRCLE  POSITION  (IBP) 

* FIRING  PIN  IMPRESSION  SHAPE  (FPI) 

* FIRING  PIN  IMP  MARKS  DESC  (TPM) 

* FIRING  PIN  DRAG  DESCRIPTOR  (FDD) 

* FIRING  PIN  POSITION  (FPP) 

* IMAGE  DATA  (IMG) 

APPO  Marker  Segment 


Compressed  Image  Data 
End  Of  Image  Marker  Code 


12.001:670031 

12.002:01  I 

1 2.003  :EVID  I 
12.004:2346ZZ  I 
12.006:BRF  s 
12.007:199602291 
12.008:Technicianl  I 
12.009:MSI  s 101  s 2.3  s SUNWS2 
s SOLARIS2.4 1 
12.010:LBIS  s 01  s 
12.01 1:44RM  I 
12.013:300  s 400 1 
12.014:12.5  s 12.51 
12.015:JPEGL  s 
12.016:2.1 1 
12.020:S  I 

12.021:140  s 180  s 100 1 
12.022:150  s 170  s 45  I 
12.023:C  I 
12.024:S  I 
1 2.025  :N  1 

12.026:  150  s 200  s 100 1 
12.999: 

XFFD2',  XFFE0', 

X'0010’,  X'4A46494600', 

X’0102',  X’1388', 

X’1388’,  X'00’,  X'00', 

< 66667  BYTE  JPEG  FILE> 
XFFD9' s 


* MANDATORY  FIELDS 
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TRANSACTION  2:  Host  system  to  remote  laboratory. 


After  the  host  system  has  performed  image  correlations  against  its  database  using  the  submitted  GCD 
as  a filter,  the  count  of  candidate  matches  (19)  is  returned  to  the  remote  laboratory.  The  remote 
laboratory  can  then  request  a list  of  the  candidate  matches  and  then  the  actual  candidate  image  files  as 
separate  transactions. 


TYPE-1  RECORD 

* LENGTH  (LEN) 

* VERSION  (VER) 

* CONTENT  (CNT) 

* TYPE  OF  TRANSACTION  (TOT) 

* DATE  (DAT) 

* DESTINATION  AGENCY  IDENTIFIER  (DAI) 

* ORIGINATING  AGENCY  IDENTIFIER  (ORI) 

* TRANSACTION  CONTROL  NUMBER  (TCN) 

* TRANSACTION  RESPONSE  NUMBER  (TRN) 

* NUMBER  OF  MATCHES  (NUM) 


1.01:123  I 
1.02:0100  1 
1.03:1  sOt 
1.04:SNDRES  I 
1.05:19960530  1 
1.07:  RVATF1 1GUN6Z  I 
1.08:  DCFBIOOGUN5Y  I 
1. 09:234567 AB  I 
1.10:RV123  I 
1.11:19  s 
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